1. Field of the Invention
The present invention relates to an apparatus and method for Firmware-Over-The-Air (FOTA). More particularly, the present invention relates to an apparatus and method for fault tolerant FOTA updating.
2. Description of the Related Art
Mobile terminals have been developed to provide wireless communication between users. As technology has advanced, mobile terminals now provide many additional features beyond simple telephone conversation. For example, mobile terminals are now able to provide additional functions such as an alarm, a Short Messaging Service (SMS), a Multimedia Message Service (MMS), E-mail, games, remote control of short range communication, an image capturing function using a mounted digital camera, a multimedia function for providing audio and video content, a scheduling function, and many more. With the plurality of features now provided, a mobile terminal has effectively become a necessity of daily life.
Software to control a mobile terminal is typically stored as firmware. Typically, in order to update the firmware, the user had to download an entire copy of the updated firmware, and then install the updated firmware on the mobile terminal. In many cases, the user had to download the updated firmware to a desktop or laptop computer to which the mobile terminal was attached, instead of controlling the updating process directly from the mobile terminal.
Recently, the concept of Firmware-Over-The-Air (FOTA) has been introduced. In this technique, an update package is delivered to the mobile terminal wirelessly. The update package includes a series of instructions which, when applied to the existing firmware, update the firmware to the newer version. An update client stored on the mobile terminal executes the instructions in the update package to modify the existing firmware and produce the updated version. Generally, the update package only includes the information needed to update the existing firmware to the new version. The update package does not include data corresponding to the portion of the firmware that is not being updated. As a result, the size of the update package is reduced.
However, problems may occur if a power loss occurs during the update process. The firmware is stored in non-volatile memory, usually either NAND flash or NOR flash. Flash memory is organized into sectors (also referred to as blocks) with a typical size between 64 KB and 256 KB. In order to modify any byte in a particular sector, the entire sector should be erased before the sector can be written to. Erasing a sector causes all the bytes to be set to 0xFF. Because of this restriction, modifying a sector is not an atomic operation; power loss in the middle of this process can cause the contents of the sector currently being updated to be in an unpredictable state. It is therefore advantageous to provide methods for fault tolerant FOTA update so that the update client can recover from power loss and resume the update successfully.
At least two major issues arise in the development of fault tolerant FOTA update methods. The first is to backup the current content of the sector about to be modified because that sector must be erased prior to updating. If a power loss occurs immediately after the sector is erased, the original content of that sector is likely needed to generate the updated content. This is referred to as the 2-phase commit algorithm.
The second issue is how the update client, when initialized after a power loss event, determines if the update has started and if so, where to resume the update. One solution to this problem is to maintain a journal which records information about each flash sector operation that has occurred. The update client can read this journal and determine which sector was last being modified at the time of power loss. However, this solution requires dedicated non-volatile memory space (generally two sectors) and requires additional sector writes during the update process, which increases update time.
Another solution to the above issue is to include checksums (also referred to as signatures) for each sector in the update package. The update client can use these checksums to determine for each sector, whether the sector has been modified, and where to resume the update. According to one exemplary implementation, the memory banks are analyzed in order. For each memory bank, the update client generates a checksum on the contents of that bank and compares this checksum to the checksum stored in the update package. The first bank whose checksum does not match its corresponding checksum stored in the update package is assumed to be the next bank to be updated. However, the remaining sectors are assumed to have their original content if a checksum does not match.
According to another proposed solution, the stored firmware image (stored in non-volatile memory) is categorized as one of four possibilities: original version, intermediate version, updated version, or alien version. This determination is made by comparing the signature of each stored block with both the original signature for that block and the updated signature for that block stored in the update package. A block is considered an original block if the signature on its stored content matches the original signature in the update package. A block is considered an updated block if the signature on its stored content matches the updated signature in the update package.
In addition, it is possible for at most one block to be corrupted due to power loss. A corrupted block is neither an original block nor an updated block. If this occurs, that block can be restored from the backup block only if the restored block can be considered an original block or an updated block. However, in this process, each block can only be updated once. Once a block is changed from an original block to an updated block, the block can never be changed again while the current update package is being applied. This is because the process determines whether a block is an updated block belonging to the updated version via the updated signature for that block stored in the update package. If a block can be updated more than once, then not only does the update package need to include a unique “updated signature” for each update, but the process for determining where to resume the update is significantly more complicated and is not obvious.
It is advantageous for the update client to have the ability to update a sector more than once when applying an update package. Each instruction in the update package may modify a particular sector, but these instructions cannot simply be put in any order in the update package. Since the update is performed in-place, each instruction modifies the stored firmware and thus each subsequent instruction must be careful not to read any of the modified parts of the firmware, because those parts do not contain content belonging to the old firmware.
The issue of reading after writing is often referred to as a Read-After-Write (RAW) conflict. If the instructions need to be placed in an order whereby each sector is only updated once, then this order is likely to force many RAW conflicts which must be resolved by either increasing the update package size or utilizing additional backup buffer space on the target. If the instructions can be placed in any order, then an order can be generated which minimizes the number of RAW conflicts. Accordingly, there is a need for a fault-tolerant FOTA update process which can reduce the size of the update package and the amount of space needed on the mobile terminal for the update process.